Stop using [ and ] as indentation menu accelerators #3229
Conversation
ffissore
added
the
Component: IDE user interface
|
Xcode uses Cmd+[ and Cmd+] for indent and unindent. I'm a fan of them too. Any reason not to support both them and tab / shift-tab? |
|
We can support both but we can only write one on the edit menu |
|
What about this? CMD+brakets are still available so, if you come from XCode, they'll just work. However TAB|SHIFT TAB are advertized on the Edit menu |
…B instead. CMD+BRAKETS are still available on MacOSX only Fixes #3224 and #220 Also see processing/processing#2199
Stop using [ and ] as indentation menu accelerators
|
At least with version 1.6.5, the functionality of [ and ] is still not correct. It used to move the entire line regardless of where the cursor was in it. Now that only works for decreasing. For increasing it adds a tab where the cursor is. I understand that this may not have been a standard feature across editors but some of us relied on it. It was an easy way to change the line indent without having to move the cursor to the beginning (requiring another key combo or mouse move). Is there any plan on returning the functionality to its original intent or are the [ and ] now just going to be a different way of hitting tab/shift-tab? |
|
Yes, please open a dedicated issue where you mention that CMD+[ is not increasing indentation but rather inserting a tab |
Use TAB/SHIFT+TAB instead. Fixes #3224 and #220
This problem affects Processing as well. See processing/processing#2199
Brackets may work on US keyboards, although no editor that I know uses them. TAB is a much more popular and widely accepted shortcut for indentation